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Abstract 


Industrial  use  of  software  product  line  technology  has  resulted  in  some  impressive  savings, 
while  also  improving  product  quality  and  delivery  time.  Although  there  has  been  some 
successful  use  of  this  technology  within  the  Department  of  Defense  (DoD),  there  are  special 
challenges.  This  paper  presents  the  basics  of  product  line  practices  and  reports  the  results  of 
two  DoD  product  line  workshops  in  which  important  issues  and  successful  practices  were 
shared. 
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1  Introduction 


Do  you  find  yourself  continually  acquiring  software-intensive  systems  that  are  similar  to  ones 
you  have  paid  for  in  the  past?  Do  you  wish  you  could  use  your  scarce  resources  to  buy  what 
is  truly  new  functionality  without  also  having  to  pay  for  re-development  of  essentially  the 
same  old  solutions?  Some  solutions  to  these  frustrations  are  found  in  a  maturing  technology 
that  is  ripe  for  exploitation:  software  product  line  practice.  Through  this  technology,  a 
growing  number  of  commercial  organizations  are  reporting  impressive  reductions  in  costs, 
faster  delivery  of  mission  capability,  and  improved  quality.  To  help  transition  this  promising 
technology  to  the  DoD,  the  Software  Engineering  Institute  (SEI)  established  the  Product  Line 
Systems  Program. 

While  this  technology  has  great  promise  and  relevance  for  DoD  needs,  key  issues  must  be 
addressed  to  take  advantage  of  this  successful  commercial  practice.  In  this  paper  we  will 
provide  some  insight  into  this  important  technology  and  its  application  within  the  DoD.  After 
providing  some  background,  including  key  concepts  and  relevance  to  the  DoD,  we  will 
present  some  practical  results  from  two  SEI  DoD  Product  Line  Workshops.  By  sharing  the 
experience  of  successful  DoD  product  line  practice,  we  hope  to  allow  others  to  take 
advantage  of  this  promising  technology. 
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2  Background 


This  section  will  provide  some  necessary  background  information.  First,  we  will  define  some 
key  terms.  Next,  we  will  provide  some  documented  evidence  of  the  benefits  of  a  product  line 
approach.  We  then  discuss  how  a  product  line  approach  supports  DoD  policy.  Finally,  we 
point  to  the  challenges  and  opportunities  to  the  DoD  that  will  be  more  fully  elaborated  in 
Section  3. 

2.1  Key  Concepts 

The  field  of  product  lines  is  new  enough  to  offer  different  definitions  for  similar  concepts. 
The  SEI  has  settled  on  a  definition  that  brings  together  the  key  intent  of  these  sometimes- 
competing  definitions.  We  define  a  product  line  to  be  a  group  of  products  sharing  a  common, 
managed  set  of  features  that  satisfy  specific  needs  of  a  selected  market  or  mission.  For 
example,  a  telecommunications  company  may  offer  a  number  of  cellular  phones  that  share  a 
similar  market  strategy  and  an  application  domain,  thus  making  up  a  product  line.  The 
products  in  a  software  product  line  can  best  be  leveraged  when  they  share  a  common 
sirchitecture  that  is  used  to  structure  components  from  which  the  products  are  built. 

The  architecture  and  components  are  central  to  the  set  of  core  assets  (sometimes  referred  to 
as  the  platform)  used  to  construct  and  evolve  the  products  in  the  product  line.  In  other  words, 
a  software  product  line  can  best  be  leveraged  by  managing  it  as  a  product  family,  which  is  a 
set  of  related  systems  built  from  a  common  set  of  assets.  For  example,  if  the  product  line  of 
cellular  phones  is  built  from  a  common  architecture  and  set  of  common  components,  it  is 
managed  as  a  product  family.  When  we  refer  to  a  product  line,  we  always  mean  a  software 
product  line  built  as  a  product  family.  This  particular  use  of  terminology  is  not  nearly  as 
important  to  us  as  the  underlying  concepts  involved,  namely,  the  use  of  a  common  asset  base 
in  the  production  of  a  set  of  related  products. 

Product  line  practice  is  therefore  the  systematic  use  of  software  assets  to  modify,  assemble, 
instantiate,  or  generate  the  multiple  products  that  constitute  a  product  line.  Product  line 
practice  involves  strategic,  large-grained  reuse  as  a  business  enabler. 

Since  software  reuse  is  not  a  new  concept,  what  is  different  about  this  from  earlier,  less 
successful  reuse  efforts?  A  key  difference  is  that  early  efforts  focused  on  small-grained  reuse 
of  code.  The  cost  of  creation  and  use  of  these  small-grained  assets  often  outweighed  the 
modest  gains.  Over  the  years,  reuse  technology  has  evolved  to  focus  on  progressively  larger- 
grained  assets.  Today,  the  state  of  the  art  is  to  reuse  strategic,  large-grained  assets  unified  by  a 
software  architecture.  Using  this  approach,  reuse  can  result  in  remarkable  efficiency  and 
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productivity  improvements  and  time  economies  [Brownsword  96,  Bergey  98].  In 
combination  with  the  known  benefits  of  process  improvement  and  technology  innovation, 
systematic  reuse  through  a  product  line  approach  offers  great  promise  to  software 
development  and  acquisition  organizations. 

2.2  Benefits  of  a  Product  Line  Approach 

A  number  of  organizations  have  already  gained  order-of-magnitude  improvements  in 
efficiency,  productivity,  and  quality  through  a  product  line  approach.  Often  even  more 
important  than  cost  savings  is  the  fact  that  product  line  practice  enables  an  organization  to  get 
its  product  to  field  more  rapidly.  As  Robert  Harrison,  Naval  Systems  Warfare  Center, 
succinctly  stated,  “The  right  answer  delivered  late  is  the  wrong  answer”  [Bergey  98]. 

A  few  examples  of  the  reported  benefits  follow.  The  Swedish  naval  defense  contractor, 
CelsiusTech,  reported  a  reversal  in  the  hardware-to-software  cost  ratio,  35:65  to  60:20,  that 
now  favors  the  software  [Brownsword  96],  Hewlett-Packard  has  collected  substantial  metrics 
showing  two  to  seven  times  cycle  time  improvements  with  product  lines.  Motorola  has 
shown  a  four  times  cycle  time  improvement  with  80%  reuse.  Cummins  engines  realized  a 
decreased  time  for  system  build  and  integration  from  about  one  year  to  three  days.  Among 
other  commercial  domains  that  have  shown  equally  dramatic  results  are  air  traffic  control 
(Thompson),  commercial  bank  systems  (Alltel),  telecommunication  systems  (Ericsson, 

Nokia,  Lucent,  AT&T),  and  college  registration  systems  (Buzzeo). 

The  reported  benefits  are  compelling,  but  what  do  you  actually  do  when  you  engage  in  a 
product  line  approach?  In  the  next  section  we  describe  the  high-level,  essential  product  line 
activities. 

2.3  The  Essential  Activities  of  a  Product  Line  Approach 

At  its  essence,  fielding  a  product  line  involves  core  asset  development  or  acquisition,  and 
product  development  or  acquisition  using  those  core  assets  [Clements  99].  These  two 
activities  can  occur  in  either  order,  or  (most  commonly)  in  concert  with  each  other.  Core  asset 
development/acquisition  has  been  traditionally  referred  to  as  domain  engineering.  Product 
development/acquisition  from  core  assets  is  often  called  application  engineering.  The  entire 
process  is  staffed,  orchestrated,  tracked,  and  coordinated  by  management.  Figure  1  illustrates 
this  triad  of  essential  activities.  The  iteration  symbol  at  the  center  represents  the  decision 
processes  that  coordinate  the  activities. 
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Figure  1:  Essential  Activities  of  Product  Lines 

The  bi-directional  arrows  indicate  not  only  that  core  assets  are  used  to  develop  products,  but 
that  revisions  or  even  new  core  assets  might,  and  most  often  do,  evolve  out  of  product 
development.  The  diagram  does  not  specify  which  part  of  the  diagram  is  entered  first.  In 
some  contexts,  already-existing  products  are  mined  for  generic  assets  that  are  then  migrated 
into  a  product  line.  At  other  times,  the  core  assets  may  be  developed  or  procured  first  in  order 
to  produce  a  set  of  products  that  is  merely  envisioned  and  does  not  yet  exist. 

There  is  a  strong  feedback  loop  between  the  core  assets  and  products.  Core  assets  are 
refreshed  as  new  products  are  developed.  In  addition,  the  value  of  the  core  assets  is  realized 
through  the  products  that  are  developed  from  them.  As  a  result,  the  core  assets  are  made 
more  generic  by  considering  potential  new  products  on  the  horizon.  Finally,  both  the  core 
asset  and  the  product  development  or  acquisition  are  themselves  iterative,  as  illustrated  in 
Figure  1. 

While  it  is  evident  that  product  line  practice  calls  for  a  new  technical  approach,  new  non¬ 
technical  and  business  practices  are  equally  crucial.  There  is  a  constant  need  for  strong 
visionary  management  to  invest  the  resources  in  the  development  or  acquisition  of  the  core 
assets  and  to  develop  the  cultural  change  to  view  new  products  in  the  context  of  the  core 
assets.  As  we  will  see,  the  non-technical  challenges  may  be  the  most  significant  for  the  DoD. 
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2.4  Relevance  and  Challenges  to  the  DoD 


Some  might  ask  what  these  largely  commercial  practices  have  to  do  with  the  DoD.  First  of 
all,  there  is  no  doubt  that  commonality  of  DoD  requirements  is  abundant.  For  example,  many 
DoD  organizations  have  developed  their  own  payroll  systems,  budgeting  systems,  and 
command  and  control  systems  that  are  essentially  duplicates  of  others.  In  response  to  this 
commonality  of  requirements,  there  is  a  growing  recognition  within  the  DoD  that  new 
acquisition  approaches  leveraging  best  commercial  practices  must  be  implemented  [Bergey 
98].  At  the  top  DoD  policy  levels,  acquisition  reform  from  DoD  Directive  5000.1  and  DoD 
Regulation  5000.2-R  have  focused  on  using  these  best  practices  to  reduce  cost,  schedule,  and 
technical  risks,  and  to  advanced  architecture-based  approaches  to  reuse  that  support  open 
systems,  interoperability,  and  commercial  off-the-shelf  (COTS)  components.  Former  and 
current  top-level  policy  makers  have  expressed  how  important  it  is  that  the  DoD  use 
innovative,  commercially  proven  practices  to  reduce  cycle  time,  improve  quality,  reduce  cost, 
improve  efficiency,  and  reduce  technical  risks.  These  facts  establish  a  clear  linkage  between 
DoD  needs,  policy  and  product  line  practice  [Bergey  99]. 

While  we  know  that  product  line  practice  works  in  industry,  many  attempts  to  emulate  this 
success  within  DoD  have  encountered  problems.  In  fact,  there  are  those  who  believe  that 
there  are  inherent  stractural  impediments  against  product  line  practice  within  DoD.  While  the 
technical  challenges  are  not  to  be  underestimated,  even  if  they  are  solved,  signiBcant  non¬ 
technical  barriers  must  be  addressed  [Foreman  96].  In  the  DoD,  many  of  these  non-technical 
issues  translate  into  acquisition-related  issues.  Yet  there  is  hope.  There  have  been  several 
reuse  efforts  within  the  DoD,  and  there  are  certainly  examples  where  the  systematic  reuse  and 
horizontal  leverage  characteristic  of  a  product  line  approach  have  occurred  and  are  occurring 
[Bergey  98]. 

Why  have  some  attempts  succeeded  where  several  have  failed?  The  successful  organizations 
have  found  ways  to  identify  and  address  some  of  the  key  acquisition-related  issues.  In  the 
next  section  we  will  present  the  results  of  two  hands-on  DoD  workshops  in  which  many 
issues  and  some  answers  were  identified.  Because  this  is  a  relatively  new  endeavor,  many 
questions  are  unresolved.  However,  there  have  been  enough  successes  to  provide  some 
optimism  for  the  future. 
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3  Some  Issues  and  Strategies  for  the  DoD  -  Product  Line 
Workshop  Resuits 


The  SEI  DoD  Product  Line  Practice  workshops  were  held  in  March  1998  [Bergey  98]  and 
March  1999.‘  Their  purpose  was  to  identify  industry-wide  best  practices  in  software  product 
lines,  to  share  DoD  product  line  experience,  to  explore  the  technical  and  non-technical  issues 
involved,  and  to  discuss  ways  in  which  the  current  gap  between  commercial  best  practice  and 
DoD  practice  can  be  bridged.  In  each  workshop,  more  than  30  workshop  participants 
represented  joint  agencies,  all  services,  non-DoD  agencies,  and  industry.  All  participants  had 
experience  with  product  lines  or  other  strategic  reuse  approaches. 

The  participants  formed  working  groups  to  consider  the  general  areas  of  software 
engineering,  technical  management,  and  organization  management  for  both  acquisition 
organizations  cuid  contractors.  After  identifying  the  specific  practices  to  discuss,  the  general 
approach  of  each  working  group  was  to 

•  describe  the  practices  in  a  DoD  context 

•  identify  barriers  for  implementing  the  practices  within  the  DoD 

•  identify  strategies  to  overcome  those  barriers 

Following  the  same  structure,  we  present  highlights  of  the  results  most  directly  related  to  a 
DoD  acquisition  organization  considering  adopting  a  product  line  approach.  Results  from 
both  workshops  are  summarized  here.  The  practices  covered  are 

•  building  and  communicating  a  business  c^e 

•  developing  and  implementing  a  product  line  Concept  of  Operations 

•  providing  an  appropriate  funding  model 

•  achieving  the  right  organizational  structure 

•  developing  and  implementing  an  acquisition  strategy 

•  contractor  interface 


‘  Bergey,  John;  et  al.  Second  DoD  Product  Line  Practice  Workshop  Report  (CMU/SEI-99-TR-015). 
Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  University.  Expected  publication; 
November  1999. 
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Please  note  that  this  list  is  not  purported  to  be  an  exhaustive  list  of  all  the  issues.  However, 
these  are  critical  issues  that  the  participants  were  able  to  address  in  the  context  of  the 
workshop. 


3.1  Building  and  Communicating  a  Business  Case 

Given  sound  business  goals  as  a  basis  for  evaluation,  a  business  case  will  play  a  strategic  role 
in  deciding  whether  a  product  line  approach  makes  sense  for  a  DoD  organization.  The  current 
environment  of  downsizing  and  escalating  demands  for  “better,  faster,  cheaper”  system 
development  may  make  building  a  business  case  more  straightforward.  While  data  from 
outside  organizations  may  be  useful  to  initiate  concept  exploration,  hard  evidence  obtained 
from  pilots  within  the  organization  is  essential. 

Participants  identified  the  following  prerequisites  for  building  the  business  case: 

•  selectivity  about  where  and  when  to  apply  a  product  line  approach  (multiple  mission 
areas  may  need  different  approaches) 

•  solid  justification  including  anticipated  savings  or  pay-back  for  candidate  systems 

•  incentives  for  achieving  efficiency 

Some  of  the  significant  barriers  to  implementing  this  practice  in  the  DoD  relate  to 
organizational  stmcture  and  funding  models.  These  will  be  discussed  later  in  this  section. 

One  mitigation  strategy  is  to  include  a  rough  draft  of  the  product  line  Concept  of  Operations 
with  the  business  case  to  provide  insight  into  how  the  product  line  concept  will  work  within 
the  organization.  This  will  help  to  substantiate  the  considerations  are,  in  fact,  valid  for  the 
organization. 

3.2  Developing  and  Implementing  a  Product  Line  Concept  of 
Operations 

Once  a  business  case  has  been  established  to  support  a  product  line  approach,  it  is  important 
to  begin  creation  of  a  product  line  Concept  of  Operations  (CONORS)^  to  define  how  the 
implementation  will  be  accomplished.  The  CONOPS  will  be  best  developed  in  an  iterative 
fashion.  As  noted  in  the  previous  section,  a  draft  CONOPS  can  be  an  important  vehicle  to 
identify  key  issues  that  must  be  resolved,  such  as  which  organizations  will  participate,  how 


^  The  CONOPS  applies  to  the  development/acquisition  and  evolution  of  the  product  line  and  should 
not  be  confused  with  the  traditional  DoD  concept  of  operations  that  describes  the  operational 
system. 
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the  approach  will  be  funded,  and  processes  and  structures  for  initiating  and  sustaining  the 
approach.  As  these  issues  are  resolved,  the  CONOPS  can  be  refined. 

A  fully  developed  CONOPS  identifies  product  line  stakeholders  and  clearly  describes  their 
roles  and  responsibilities.  Typical  contents  include  appropriate  mechanisms  for  sustaining 
the  product  line  over  its  life  cycle,  improvement  feedback  mechanisms,  customer  interface, 
and  other  support  functions  essential  for  long-term  success.  The  CONOPS  should  address  the 
operation  of  both  the  acquisition  organization  and  development  groups  as  well  as  the  role  of 
the  product  line  architecture. 

Workshop  participants  stressed  that  the  key  pitfall  in  creating  a  CONOPS  was  to  adopt  a  “Big 
Bang”  strategy  that  was  too  grandiose.  Such  a  strategy  ignores  the  reality  that  a  product  line 
approach  should  evolve  incrementally,  preferably  from  grassroots  support  that  builds  upon 
initial  successes  within  the  organization.  Since  the  CONOPS  describes  how  a  product  line 
approach  will  work  in  a  particular  environment,  the  document  itself  can  serve  as  a  practical 
way  to  identify  a  wide  range  of  barriers  and  how  the  organization  will  mitigate  them. 

The  SEI  has  developed  guidance  for  CONOPS  creation  based  on  experience  with  several 
government  organizations  [Cohen  99].  This  may  be  found  on  the  SEI  Web  site 
(http://www.sei.cmu.edu). 

3.3  Achieving  the  Right  Organizationai  Stracture 

A  key  part  of  a  product  line  CONOPS  is  a  description  of  the  organizational  structures 
involved.  The  workshop  participants  agreed  that  achieving  the  right  organizational  structure 
is  one  of  the  greatest  challenges  in  implementing  a  product  line  approach.  Implementing  a 
product  line  approach  is  dependent  on  managing  horizontally  (i.e.,  in  a  matrix  mode)  across 
projects  to  produce  products  that  are  part  of  a  family  built  around  a  common  architecture  and 
core  set  of  assets,  as  well  as  managing  vertically  to  create  individual  products.  This  presents  a 
real  challenge  for  DoD  organizations  that  are  traditionally  highly  “stovepiped”  with  regard  to 
their  sponsorship,  project  structure,  funding,  resources,  contracting,  and  reward  system.  As 
one  participant  stated,  “we  [in  the  DoD]  are  horizontally  challenged.” 

A  primary  consideration  in  a  product  line  approach  is  structuring  the  organizational  units 
responsible  for  developing/acquiring  and  sustaining  the  core  assets  versus  those  responsible 
for  developing/acquiring  derivative  products  using  the  core  assets.  These  organizational 
considerations  raise  many  questions  about  control  and  funding  of  the  architecture  and  other 
core  assets,  how  the  core  assets  will  be  responsive  to  project-specific  requirements,  and 
support  for  acquisition  of  assets  and  products. 

The  wrong  organizational  structure  can  defeat  solid  product  line  technology  and  processes. 
Moreover,  achieving  the  right  organizational  structure  involves  both  determining  the 
appropriate  structure  and  an  effective  strategy  to  implement  it.  It  is  also  the  case  that  the 
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definition  of  the  right  organizational  structure  may  change  as  the  product  line  matures.  The 
challenge  in  creating  such  a  suitable  organizational  structure  is  to  avoid  making  wholesale 
changes  that  can  be  unduly  disruptive  to  the  culture  of  the  work  place,  while  at  the  same  time 
trying  to  align  the  organization  with  product  line  goals  that  cut  across  project  efforts.  The 
working  group  again  returned  to  the  theme  of  starting  small  as  a  key  risk  mitigation  means. 
Choose  a  well-scoped  product  line  with  modestly  scoped  organizational  change  rather  than 
attempt  a  risky  enterprise  overhaul. 

3.4  Providing  an  Appropriate  Funding  Modei 

The  funding  model  is  closely  linked  to  the  CONOPS,  organizational  structure,  and  the 
business  case.  This  model  identifies  funding  sources  to  initiate  and  support  the  product  line 
approach.  Developing  a  suitable  funding  model  involves  clearly  laying  out  a  product  line 
approach  over  multiple  systems  and  identifying  the  life-cycle  cost  savings  and  benefits  to 
senior  level  management  to  obtain  their  buy  in. 

One  of  the  participants  stated  that  “seed  money”  is  essential  to  overcoming  objections,  and 
without  it  there  may  be  no  practical  way  to  get  started  and  demonstrate  savings.  Although 
there  was  general  agreement  that  the  product  line  startup  risk  should  ideally  be  addressed 
through  research  and  development  (R&D),  the  current  funding  structure  often  works  against 
this. 

Suggestions  for  creating  a  funding  model  include  the  following: 

•  obtaining  grassroots  support  to  convince  sponsors  and  projects  of  the  benefit  of  the 
product  line  solution  rather  than  management  directing  a  solution 

•  reallocating  a  portion  of  the  funds  from  programs  that  will  benefit  from  the  product  line 
approach  and  using  those  moneys  to  fund  the  product  line 

•  aligning  funding  to  support  the  long-term  plan  and  justifying  seed  money  from  other 
areas  (including  using  R&D  funds  for  pilot  projects) 

•  creating  a  horizontal  funding  line  as  a  firm  part  of  the  budget  based  on  product  line 
feasibility  and  return  on  investment 

A  major  barrier  that  was  cited  is  that  the  organizational  unit  responsible  for  developing  the 
Concept  of  Operations  is  not  usually  in  charge  of  the  funding  model.  This  reemphasizes  the 
need  for  a  product  line  funding  mechanism  that  can  align  sponsorship  with  horizontal  areas 
that  cut  across  projects.  Other  barriers  that  were  discussed  include  funding  instability, 
parochial  views  of  organizations  opposed  to  the  pooling  of  funds,  restrictions  on  the  use  of 
funds  (e.g.,  color  of  the  money),  and  a  lack  of  incentives  for  an  enterprise  approach  to 
systems  development  that  transcends  organizational  units  and  commands. 
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3.5  Developing  and  Implementing  an  Acquisition  Strategy 

All  of  the  participants  indicated  that  developing  and  implementing  a  suitable  acquisition 
strategy  is  critical  to  achieving  a  product  line  approach  in  DoD.  One  of  the  key  perceived 
differences  in  implementing  a  product  line  approach  in  the  DoD  environment,  as  opposed  to 
commercial  ventures,  is  the  predominant  role  that  acquisition  plays.  The  acquisition  strategy 
defines  how  to  deal  with  product  lines  within  the  contracting  environment  of  the  DoD  and 
still  be  responsive  to  unique  project  requirements.  One  participant  suggested  that  the  DoD 
contracting  environment  provides  a  lot  of  freedom;  a  big  challenge  is  to  find  the  appropriate 
contractual  vehicle  and  recognize  that  the  early  “buy-in”  and  endorsement  of  the  contracting 
officer  and  contract  negotiator  play  a  very  pivotal  role  in  the  acquisition  strategy. 

A  key  issue  for  the  DoD  participants  in  developing  a  product  line  acquisition  strategy  was 
how  to  competitively  acquire  derivative  products  without  endangering  contractor  interests  or 
the  government's  ability  to  maintain  control  over  the  core  assets.  Another  concern  is  the  issue 
of  liability  for  any  government-provided  components. 

A  common  concern  of  the  group  is  that  proven  acquisition  approaches  (i.e.,  ones  that  are 
repeatable  and  responsive  to  life-cycle  requirements)  constitute  a  major  unknown,  and  will 
need  to  be  gradually  developed,  refined,  validated  in  actual  practice,  and  disseminated. 
Guidance  is  especially  needed  on  how  to  include  architecture  issues  in  a  Request  for 
Proposals  (RFP). 

The  participants  of  the  Second  DoD  Workshop  identified  several  different  specific  acquisition 
strategies.  Generally,  these  strategies  differed  in  the  degree  to  which  the  government  owned 
the  product  line  assets.  In  increasing  ownership  of  assets  these  strategies  were 

•  to  acquire  a  product  built  using  product  line  technology  (no  government  ownership  of 
assets) 

•  to  acquire  a  reference  architecture  to  serve  as  a  basis  for  future  acquisitions  of  specific 
system  architectures,  assets,  and  products 

•  to  acquire  a  system  architecture  and  a  set  of  components  from  which  future  systems  may 
be  built.  The  US  Army  Common  Hardware/Software  (CHS)  system  is  a  successful 
example  of  this  strategy. 

•  to  acquire  a  system  architecture,  a  set  of  components,  and  at  least  one  product  built  using 
these  assets.  The  US  Army  Crusader  howitzer  program  is  a  successful  example  of  this. 

Generally,  as  you  work  up  the  scale  of  increasing  government  ownership  of  assets,  the  risks 
associated  with  having  unvalidated  assets  decreases.  However,  the  risks  associated  with  the 
scope  of  the  acquisition,  the  expense,  and  the  commitment  required  increases. 
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Other  areas  where  it  was  indicated  that  acquisition  guidance  is  needed  to  support  a  product 
line  approach  include 

•  developing  an  acquisition  plan  and  selecting  a  suitable  contract  vehicle(s)  that  is 
compatible  with  the  product  line  concept  and  takes  full  advantage  of  Acquisition  Reform 
measures 

•  preparing  solicitation  packages  and  specifying  appropriate  technical  evaluation  criteria 

•  including  precautionary  measures  to  minimi2e  the  risk  of  a  protest  before  or  after 
contract  award 

•  incorporating  contract  incentives  to  sustain  contractor  motivation  (after  contract  award), 
and  to  encourage  cooperation  and  efficiency  commensurate  with  their  role  as  a  product 
line  team  player 

All  of  these  measures  are  aimed  at  overcoming  the  traditional  mindset  of  a  single-system 
acquisition  program  and  accommodating  multiple  project  efforts. 

3.6  Contractor  Interface 

Members  of  the  group  observed  that  at  the  organizational  level,  the  interface  to  the  contractor 
and  the  contractor  product  line  practices  seemed  to  be  tightly  coupled  to  the  acquisition 
approach  of  the  DoD  project.  At  least  for  traditional,  single-system  acquisitions,  the  business 
and  funding  models;  the  organizational  structure  and  operations;  the  resource  development 
and  allocation  processes;  and  other  senior  management  practices  seemed  to  be  based  on  the 
customary  acquisition  practices  of  the  DoD. 

Comparing  the  traditional  enterprise  to  the  product  line  enterprise,  a  few  issues  come  to  the 
forefront. 

The  first  issue  concerns  the  contractor’s  business  model.  Contractors  now  have  multiple  and 
different  business  opportunities.  They  can  focus  their  business  on  one  or  more  of  three  roles 

1 .  lead  contractor  for  architecture 

2.  subsystem/asset  developer 

3.  systems  developer/integrator 

The  presence  of  choices  raises  important  questions,  such  as 

•  What  are  the  criteria  that  would  lead  a  contractor  to  choose  one  business  opportunity  over 
another? 

•  Would  not  most  contractors  opt  to  lead  architecture  development  for  the  contract  security 
and  competitive  advantage  it  provides  over  asset  developers  and  system  integrators? 
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The  second  issue  concerns  shared  commitment.  For  a  product  line  approach  to  be  successful, 
the  working  group  believed  that  contractors  and  the  acquisition  organization  must  share 
responsibility  and  commitment  to  cost  avoidance  through  systematic  reuse.  How  is  this 
achieved? 

The  third  issue  concerns  contractor  buy-in  of  a  product  line  architecture.  Systems  integrators 
will  not  be  motivated  to  use  a  mandated  product  line  architecture  that  may  not  reflect  their 
design  practices.  System  development  risks  and  costs  may  be  greater,  particularly  if  the 
contractor  has  no  experience  and  assurance  that  the  architecture  is  valid.  The  architecture  will 
be  “dead  on  arrival.”  How  is  this  scenario  avoided? 

Having  all  interested  contractors  collaborate  on  developing  a  product  line  architecture  may 
resolve  the  above  issues,  but  this  may  not  be  feasible  in  all  cases.  For  example,  the 
architecture  may  be  an  open  systems  standard,  or  only  one  contractor  may  have  the  needed 
expertise.  In  addition,  are  there  cases  when  the  performance  and  schedule  risk  of  an 
architecture  by  consensus  is  too  great? 

There  are  no  clear-cut  answers  to  these  issues,  but  a  joint  government-industry  approach  to 
these  issues  must  be  developed  for  long-term  product  line  success. 
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4  Summary  and  Conclusions 


There  are  many  benefits  to  a  product  line  approach  and  many  organizations  have  succeeded 
in  realizing  these  benefits.  Yet  there  are  also  costs  and  risks  for  any  product  line  program. 
Nevertheless,  if  properly  managed,  the  benefits  of  a  product  line  approach  far  exceed  the 
costs.  Strategic  software  reuse  through  a  well-managed  product  line  approach  holds  great 
promise  for  the  DoD  in  terms  of  efficiency,  time  to  field  mission  capability,  and  quality. 

The  SEI  vision  for  product  lines  is  that  this  practice  will  pervade  software  engineering  in  the 
new  millennium,  and  we  are  committed  to  helping  the  DoD  succeed  in  the  successful 
exploitation  of  this  technology.  To  assist  in  this  exploitation,  the  SEI  Product  Line  Systems 
Program  has  established  the  Business  Acquisition  Guidelines  project.  This  project  exists  to 
address  product  line  acquisition  challenges  within  the  DoD.  We  invite  you  to  visit  our  Web 
site  to  learn  more  about  our  work  in  this  important  area: 
(http://www.sei.cmu.edu/plp/bus_acq_guide.html). 
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Appendix  A:  A  Product  Line  Practice  Framework 


The  SEI  is  capturing  the  essential  elements  of  product  line  practice  in  an  evolving 
framework,  A  Framework  for  Software  Product  Line  Practice.  Organizations  that  have 
succeeded  with  product  lines  vary  widely  in  the  nature  of  their  products,  their  market  or 
mission,  their  organizational  structure,  their  culture  and  policies,  their  software  process 
maturity,  and  the  extensiveness  of  their  domain  expertise  and  legacy  artifacts.  Nonetheless, 
there  are  universal  essential  elements  and  practices  that  are  emerging.  The  framework  focuses 
on  these  universal  while  accommodating  various  organizational  contexts  and  starting  points. 

There  are  essential  practices  in  a  number  of  specific  areas  that  are  required  to  produce  the 
core  assets  and  products  in  a  product  line  and  to  manage  the  process  at  multiple  levels.  The 
framework  describes  the  essential  practice  areas  for  software  engineering,  technical 
management,  and  organizational  management,  where  these  categories  represent  disciplines 
rather  than  job  titles.  For  individual  practice  areas,  the  framework  highlights  the  delta  for  the 
product  line  approach  versus  an  approach  for  single-system  development. 

The  Framework  is  a  living  document  that  is  being  developed  incrementally  and  validated  and 
updated  based  on  feedback  from  practitioners.  To  view  the  most  recent  version  of  the 
Framework,  please  visit  the  SEI  web  site  at  http://www.sei.cmu.edu. 
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